Most modem, mid-range to high-end disk storage subsystems are arranged as redundant arrays of independent disks (RAID). A number of RAID levels are known. RAID-1 includes sets of N data disk drives and N mirror disk drives for storing copies of the data disk drives. RAID-3 includes sets of N data disk drives and one parity disk. RAID-4 also includes sets of N+1 disk drives. RAID-5 distributes parity data across all disk drives in each set of N+1 disk drives.
A RAID subsystem must be configurable. That is, the arrays, which perform I/O operations for users, must be created, managed, and deleted. Many other functions of the RAID subsystem must also be performed, such as on-line expansion, RAID level migration, and assigning spare space. A configuration description of the arrays must also be readable, and configuration applications must be able to monitor the arrays during operation. For that reason, a configuration interface and module are included with all RAID subsystems.
FIG. 1 shows components of a computer system 10 including a typical prior art RAID subsystem 100. The RAID subsystem 100 includes a RAID configuration module 101, and one or more RAID user data arrays 102 each with their own array Identification (ID) 104. User applications 111 use a block I/O path 121 to read and write, generally “access,” user data of the RAID arrays 102 using the ID 104 assigned to each array. Physically, the RAID arrays 102 store the user data on block storage devices 130.
The problem with the prior art RAID subsystems is that a configuration application 110 must use a specialized configuration path 120 to communicate with the configuration module 101 to perform the configuration functions described above.
FIG. 2 shows the layers of the block I/O path or calling stack 121 used for user data transfer. The software and hardware of the block I/O path 121 includes, from the top host side to the bottom client side, an operating system (O/S)—application interface 201, an O/S driver interface 202, an I/O driver 203, a host transport interface 204, an I/O transport 205, a client or external transport interface 206, a transport driver 207, and a RAID subsystem interface 208.
The interface 201 translates I/O requests executed by the user applications 111 for the O/S driver interface 202. The I/O driver 203 translates specific O/S calls for the transport layer 205, such as PCI, iSCSI, Infiniband, SCSI, or fibre-optic channel, or some other high bandwidth bus. The transport driver 207 communicates with the RAID subsystem interface 208, which in turn communicates with the RAID subsystem 100.
The block I/O path 121 is relatively straightforward because most operating systems and buses use the same basic functions. Only minor differences are found among operating system interfaces. Typically, most of the layers of the stack that form the block I/O path 121 are well defined. The O/S—application interface 201, the O/S driver interface 202, transport interfaces and transport 204-206 are typically standardized. Some of the drivers and interfaces may be specialized or proprietary. For instance, most RAID subsystems require a specially designed I/O driver 203, transport driver 207, and RAID subsystem interface 208.
However as shown in FIG. 3, the layers of the stack that form the configuration path 120 generally have far more specialized components than the block I/O path. A configuration interface 301 to the configuration application 110 is typically a proprietary set of IOCTLs (I/O control commands) that need to be designed and defined. A configuration driver 302 implements these specialized IOCTLs to allow control of the RAID subsystem 100. The transport layers 303-305, which also can use SCSI, fibre, or PCI buses, have specialized block I/O commands, and usually the specialized transport interface 303 is customized. For SCSI buses, for instance, the transport interface 303 uses mode pages with devices. In fact, many RAID subsystems even include a separate third physical path, such as Ethernet, or serial ports to implement the transport layers 303-305. The driver or external side transport interface 305 also uses specialized primitives that communicate with a specialized transport driver 306, and of course a specialized RAID configuration interface 307.
In all RAID subsystems, the configuration interface 301, configuration driver 302, host side configuration transport interface 303, client side configuration transport interface 305, transport driver 306 and RAID configuration interface 307 are specialized. Additionally, many RAID subsystems even have a specialized configuration transport 304.
Therefore, current RAID subsystems have a severe problem. The configuration portions perform many functions, yet these are not pre-defined. Every operating system requires a re-implementation of the configuration functions and interfaces, and every configuration application needs specialized software, and perhaps, access to specialized hardware. This increases the cost and complexity of the computer system 10.
Even if the configuration stack 120 were as easy to implement as the block I/O stack 121, it is still requires a completely separate implementation to communicate with the configuration module 101. A lot of effort is required to make this possible. In addition, the configuration path 120 often has many limitations with respect to the number of commands and the amount of information that it can process.
Therefore, there is a need for a RAID subsystem that does not require a specialized configuration path so that the cost and complexity of the entire computer system can be reduced.